feat(api): support v2 namespace endpoints in @supabase/api - #6142
Merged
Coly010 merged 7 commits intoAug 11, 2026
Merged
Conversation
Fetch and merge both Management API OpenAPI documents (/api/v1-json and
/api/v2-json), derive client namespaces from the path, and regenerate the
snapshot so v2 operations are callable as api.v2.<operation>.
- download-openapi.ts: two-document fetch (hard-fail on a missing doc),
structural merge with collision asserts, tolerant remove override op,
committed source pin in scripts/openapi-source.json (staging for now:
GET /v2/projects/{ref}/config has not shipped to prod yet)
- generate.ts: version namespace derived from the leading path segment,
duplicate-operation hard error; v1 output is byte-identical
- openapi-overrides.json: remove the v2 webhook paths (upstream spec bug:
duplicated, non-version-prefixed operationIds) and APIErrorObject
- api-package-sync.yml: pin hourly sync to prod, diff the source pin
- generate:check script + README spec-pipeline/override/merge-gate docs
- generated-contract-sync.unit.test.ts: bijection between the committed openapi.json snapshot and the generated contracts/effect client, so a hand-edited snapshot or client fails CI - client.unit.test.ts: 404 on a v2 operation surfaces as a StatusCodeError with the response status; v2 requests carry identical auth/base-url wiring; nested V2ProjectConfigResponse payload decodes strictly - effect.unit.test.ts: same-named v1/v2 operations are separately addressable per namespace - export OpenApiDocument/OpenApiOperation types from generate.ts for typed test fixtures
ApiClient now carries a v2 namespace, so the v1-only mock object no longer overlaps the ApiClient type. The legacy shell only calls v1 operations; v2 calls die loudly as wiring bugs.
GET /v2/projects/{ref}/config shipped to production (byte-identical to
the staging definition the snapshot was generated from), so regenerating
from prod reproduces the committed snapshot exactly — only the source
pin changes. Drops the temporary staging warnings.
Coly010
marked this pull request as ready for review
August 11, 2026 10:25
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 969c85e9b0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Contributor
Supabase CLI previewnpx --yes https://pkg.pr.new/supabase/cli/supabase@e57345649f794f1f727f333aa17703e200b8fffdPreview package for commit |
…ource-pin precedence Review follow-ups on #6142: - New generated-output-sync test re-renders contracts.ts, effect-client.ts and openapi.json from the committed snapshot through the same oxfmt the pipeline uses and requires byte equality, so hand edits to schemas, parameters, request bodies, response types, or the executor fail plain PR CI (the prior bijection test only covered operation-level identity) - mergeOpenApiDocuments now emits only the keys the generator consumes; upstream servers/tags/securitySchemes no longer appear even in the intermediate write between generate:spec and generate.ts, which is the state that presented as snapshot drift during review - SUPABASE_API_URL now takes precedence without reading the source pin, and a missing pin falls through to the default instead of throwing - generate:check invokes pnpm generate rather than bun run generate
jgoux
approved these changes
Aug 11, 2026
Bun on Linux truncates a child process's piped stdout at ~219KB, so the stdin/stdout round-trip through oxfmt cut the 600KB+ renders mid-line on CI while passing on macOS. File mode writes and reads through the filesystem — no pipe — and is also what the pipeline's fmt:fix runs, which drops the stdin-mode trailing-newline normalization too.
Coly010
deleted the
columferry/cli-2157-support-v2-namespace-endpoints-in-supabaseapi
branch
August 11, 2026 15:03
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
`@supabase/api` previously modeled only the Management API v1 namespace. The upstream API publishes two OpenAPI documents (`/api/v1-json` and `/api/v2-json`), and the config endpoint needed by CLI-2156/CLI-2064 lives on v2. This PR makes v2 a first-class namespace:
The proving case, `GET /v2/projects/{ref}/config` → `api.v2.getProjectConfig` (typed `V2ProjectConfigResponse`), was staging-only when this branch started; it shipped to production on 2026-08-11 with a byte-identical definition, the snapshot regenerates from prod exactly, and the source pin now points at prod. No merge gate remains.
Known limitation
Three v2 operations (`v2-list-organization-members`, `v2-list-organization-projects`, `v2-list-organization-github-connections`) declare `style: deepObject` object query params, which the client currently serializes as JSON strings rather than `page[size]=...`. Documented in the README; the typed surface is correct, the wire format for those params is not.
Part of CLI-2157 (unblocks CLI-2156 and CLI-2064).